Subject: Re: New hardware reference guide?
From: [email-masked] (Peter Cherna)
Date: 16 Nov 92 14:37:23 GMT
Newsgroups: comp.sys.amiga.programmer

In article <[email-masked]> [email-masked] (Bjoern Reese) writes:
>In article <[email-masked]> [email-masked] (Chris  
>Green) writes:
>> In article <[email-masked]> [email-masked] writes:
>> >Come on now!! How many advanced system software, that was written on a
>> >1.3 A500 with no harddrive will work on a A4000???
>> 	A LOT.
>
>Ahhh! But not all? That's interesting.
>
>Does anybody have any info (what software did break, and what
>was the possible cause?)

Sure.  There are lots of reasons stuff that ran under 1.3 on A500's
breaks on the A4000.  Here is a partial list, off the top of my head:

- Breaks under ECS or higher (writing to chip registers that were
  undefined under the original chipset, writing non-zero values
  to reserved bits of existing registers, failing to handle non-zero
  values in reserved bits when reading existing registers)
- Breaks under AA or higher (same basic kinds of reasons, also
  making bad assumptions about the chipset)
- Breaks with fast RAM installed (forgetting to request MEMF_CHIP
  when necessary)
- Breaks on a 1MB chip-RAM system with no fast RAM (assumes if memory
  > 512K, then some MEMF_FAST must be available).
- Breaks on a 2MB chip-RAM system with no fast RAM (eg. A1200).  Same
  reason as above.
- Breaks on 68020 and up, 68030 and up, or 68040 and up.  The usual
  reasons are:
	- Software timing-loops or other processor speed dependencies
	- Use of "MOVE SR" instruction (priviledged on 68010)
	- Self-modifying code fails to work due to presence of caches
	  (depending on the code path and cache size, you might work
	  on the 020 and 030 but not the 040, for example)
	- Use of high 8 bits of address pointer to store type-data
	  (all Amiga pointers must be 32-bit accurate)
	- Has an enforcer hit (this is generally fatal on 68040 and up)
- Breaks due to dependency on undocumented side-effect of the OS.  Some
  examples:
	- Depending on certain registers defined as "trash" actually
	  being preserved across a function call.
	- Assuming values of "trash" registers, eg. "noticing" that
	  A1 points to the RastPort on the return from a certain
	  graphics call.
	- Taking the return code from the wrong register (eg. D1 or A0).
	- Depending on "slowness" of the OS.  New releases often have
	  faster routines, and one source of problem is a race condition
	  or a missing WaitBlit() that you survive only by virtue of
	  having a slower CPU or an older (less optimized) OS.
	- Poking read-only members of structures or private structures
	  (eg. writing to IntuitionBase)
	- Passing the wrong flag to a function or a structure.  (The
	  best example of this is placing the IDCMP flag ACTIVEWINDOW
	  into the NewWindow.Flags field by mistake.  V35 added a NewWindow
	  flag with that numeric value.  This caused massive enforcer hits
	  and software death -- we put in a kludge to protect against this
	  case).
	- Passing non-zero values in reserved fields (eg. BitMap->Pad byte).
- Breaks due to "abuse of system".  Examples include:
	- Incorrectly or incompletely taking over the system
	- Not using system-supplied mechanisms (one application
	  "knew" that under 1.3, audio.device was third (or whereever, it
	  doesn't matter what the exact position was) on the device list.
	  Rather than call OpenDevice(), it just took the third device
	  pointer.
	- Assuming the ROM size or location.  (jumping to the start of the
	  ROM in order to reset the computer amounts to jumping to middle
	  of the ROM now that the ROM is 512K large).
	- We have well-defined requirements on floppies, as far as
	  the settle-times, track-to-track times, etc.  Some programmers
	  empirically determine that they can shave (say) 3 ms off every
	  seek.  Not all drives sold for the Amiga can handle this.
	- Similarly, violating the timing and handshaking requirements
	  of the keyboard.

There are plenty of other reasons, but these are a pretty good sampling.
Virtually _all_ of these were addressed in some form or other, even
in the original 1.0 RKMs.

In fairness, you have to add to the list such OS-related problems as:
- Changes in poorly-defined areas of the system.  Occasionally, the
  exact behavior of a function changes due to the fact that we are
  unaware how certain non-documented or under-documented aspects
  have been used in the field.
- Accidental changes in behavior of a system function.  Sometimes
  in extending, enhancing, or speeding up a function, a small behavioral
  aspect might be altered.  If this aspect was part of the function's
  definition, then that would consitute a bug.  If not, then it
  may not technically be a bug, but it can kill software.

>Bjoern Reese                   |     Email: [email-masked]

     Peter
--
Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter    [email-masked]
My opinions do not necessarily represent the opinions of my employer.
"I believe it's bad luck to be superstitious."